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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Eureka Project 147 was established in 1987, with funding from the European Commission, to develop a system for 
the broadcasting of audio and data to fixed, portable or mobile receivers. Their work resulted in the publication of 
European Standard, EN 300 401 [7], for DAB (see note) which now has worldwide acceptance. The members of the 
Eureka Project 147 are drawn from broadcasting organizations and telecommunication providers together with 
companies from the professional and consumer electronics industry. 

NOTE: DAB is a registered trademark owned by one of the Eureka Project 147 partners. 
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Scope 



The present document specifies the transport of IPDC services using the MSC stream mode of DAB (EN 300 401 [7]) 
including additional error protection (TS 102 427 [8]). IPDC services, e.g. audio and video services, are packetized and 
synchronized using RTF [15] and appropriate RTF payload format specifications. The present document specifies the 
mechanism for the multiplexing of the multimedia data using MFEG-2 TS [11]. For efficiency, some appropriate 
restrictions to MFEG-2 TS and an efficient transmission method for FSI/SI and SAT sections are specified. The present 
document also specifies methods of macro and micro time slicing for power-efficient transmission of IFDC Services in 
DAB systems. The methods for sub-channel synchronization and data arrangement are specified. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Freferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 101 756: "Digital Audio Broadcasting (DAB); Registered Tables". 

[2] ETSI TS 102 470: "Digital Video Broadcasting (DVB); IF Datacast over DVB-H: Frogram 

Specific Information (FSI)/Service Information (SI)". 

[3] ETSI TS 102 471: "Digital Video Broadcasting (DVB); IF Datacast over DVB-H: Electronic 

Service Guide (ESQ)". 

[4] ETSI TS 102 474: "Digital Video Broadcasting (DVB); IF Datacast over DVB-H: Service 

Furchase and Frotection" . 

[5] ETSI TS 102 472: "Digital Video Broadcasting (DVB); IF Datacast over DVB-H: Content 

Delivery Frotocols". 

[6] ETSI TS 102 005: "Digital Video Broadcasting (DVB); Specification for the use of Video and 

Audio Coding in DVB services delivered directly over IF protocols". 
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[7] ETSI EN 300 401 : "Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile, 

portable and fixed receivers". 

[8] ETSI TS 102 427: "Digital Audio Broadcasting (DAB); Data Broadcasting - MPEG-2 TS 

streaming". 

[9] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[10] ITU-R Recommendation BT.709: "Parameter values for the HDTV standards for production and 

international programme exchange". 

[11] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio information - Part 1: Systems". 

[12] ITU-T Recommendation H.264: "Advanced video coding for generic audiovisual services ". 

[13] ISO/IEC 14496-10 (2005): "Information Technology - Coding of audio-visual objects - Part 10: 

Advanced Video Coding". 

[14] ISO/IEC 14496-3: "Information technology - Coding of audio-visual objects - Part 3: Audio". 

[15] IETF RFC 3550: "RTP, A Transport Protocol for Real Time Applications". 

[16] IETF RFC 3926: "Flute - File Delivery over Unidirectional Transport". 

[17] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 102 473: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Use Cases and 

Services". 

[i.2] ETSI TR 102 469: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Architecture". 

[i.3] ETSI TR 101 21 1: "Digital Video Broadcasting (DVB); Guidelines on implementation and usage 

of Service Information (SI)". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

DAB IPDC Service: DAB Service transporting one or more IPDC Services 

IPDC Service: offer from a service provider to which media content is related. 

NOTE: The IPDC Service uses the MPEG Service for transport 

MPEG Service: transport service for IPDC Services 

NOTE: In DVB/MPEG Systems (ISO/IEC 13818-1 [1 1]) the normal understanding of an MPEG Service is an 
Audio and Video Service 
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3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

= Assignment operator 

!= Relational operator: Not equal to 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

A/V AudioA^ideo 

AAC Advanced Audio Coding 

ALC Asynchronous Layered Coding 

AV Audio-Visual 

bslbf Bit string, left bit first. 

NOTE: "Left" is the order in which bit strings are written in the present document. Bit strings are written as a 
string of Is and Os within single quote marks, e.g. '1000 0001'. Blanks within a bit string are for ease of 
reading and have no significance. 

CAT Conditional Access Table 

CBMS Convergence of Broadcast and Mobile Services 

CIF Common Interleaved Frame 

COFDM Coded Orthogonal Frequency Division Multiplex 

CRC Cyclic Redundancy Check 

CU Capacity Unit 

DAB Digital Audio Broadcasting 

DMB Digital Multimedia Broadcasting 

DVB Digital Video Broadcasting 

DVB-H DVB-Handheld 

DVB-T Digital Video Broadcasting - Terrestrial 

FIT Fvent Information Table 

FPG Flectronic Programme Guide 

FSG Flectronic Service Guide 

FSM Enhanced Stream Mode 

FFC Forward Frror Correction 

FIC Fast Information Channel 

FLUTF File deLivery over Unidirectional Transport 

H.264/AVC H.264/Advanced Video Coding 

HDTV High Definition Television 

HF AAC High-Ffficiency Advanced Audio Coding 

HTML Hyper Text Markup Language 

IFC International Flectro technical Commission 

INT IP Notification Table 

IP Internet Protocol 

IPDC IP Data Casting 

ISO International Organization for Standardization 

LCT Layered Coding Transport 

MBMS Multimedia Broadcast/Multicast Service 

MPF Multi Protocol Encapsulation 

MPEG Moving Pictures Experts Group 

MPEG-2 TS MPEG-2 Transport Stream 

MPEG-2 MPEG Standard for Generic Coding of Moving Pictures and Associated Audio (ISO/IEC 13818) 

MSC Main Service Channel 

NIT Network Information Table 

PAT Programme Association Table 

PCR Programme Clock Reference 

PID Packet IDentifier 

PMT Programme Map Table 
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PNG Portable Network Graphics 

PSI Programme Specific Information 

PSNR Peak Signal-to-Noise Ratio 

RF Radio Frequency 

RS Reed-Solomon 

RTP Real-time Transport Protocol 

SAT Sub-channel Assignment Table 

SDP Session Description Protocol 

SDT Service Description Table 

SI Service Information 

SRTP Secure Real-time Transport Protocol 

TDT Time and Date Table 

TS Transport Stream 

TSDT Transport Stream Description Table 

UDP User Datagram Protocol 

uimsbf Unsigned integer, most significant bit first 

NOTE: The byte order of multi-byte words in the coded bit-stream is most significant byte first. 



UMTS 

VBR 

XML 



Universal Mobile Telecommunications System 
Variable Bit Rate 
Extensible Markup Language 



4 General concept and structure 

4.1 DAB IPDC system architecture 

The idea of DAB IPDC is to transmit IP Datacast (IPDC) Services over DAB (EN 300 401 [7]) taking into account the 
transport of IPDC over MBMS and DVB. For the transport the DAB IPDC Layer is defined which is placed on top of 
the MSC streaming mode of the DAB system. Figure 1 shows the DAB IPDC Layer in the context of different 
transmission systems. 
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Figure 1 : DAB IPDC in the context of other transmission systems 

IP Datacast over DAB is an end-to-end broadcast system for delivery of any type of digital content using IP-based 
mechanisms optimized for devices with limitations on computational resources and battery. The most important 
DAB IPDC application is the efficient transport of multiple audiovisual services based on H.264/AVC video coding 
[12] & [13] using optional statistical multiplex and HE- A AC audio coding [14]. 



ETSI 



9 ETSI TS 1 02 978 V1 .1 .1 (2008-07) 

The IPDC Architecture used in DAB is aUgned to the specifications of IPDC from the DVB-CBMS (Convergence of 
Broadcast and Mobile Services) working group. IPDC includes the specification of: 

Usage of PSI/SI 

Elementary Use Cases 

Reference Architecture for IPDC Service Delivery 

Electronic Service Guide (ESG) 

Service Purchase and Protection (SPP) 

Content Delivery Protocols (CDP) 

A detailed description of mandatory IPDC documents is given in clause 5.1. 



4.2 DAB IPDC protocol stack 



The DAB IPDC protocol stack differs only in the bottom layer from the protocol stack which is used for DVB-H. In 
Figure 2 the respective protocol stacks are shown, the only difference is the transport of the MPEG-2 TS over DAB 
instead of DVB-H. The usage of every layer is covered by existing specifications and equivalent layers will be handled 
in the same way for DAB IPDC as for DVB-H. The transport of the MPEG-TS in DAB is based on TS 102 427 [8] in a 
flexible and power efficient way, which is specified in this clause. 



FLUTE 
RTP/SRTP ALC/LCT 



PSI/SI 



UDP 
IP 



MPE 
MPEG-2 TS 



DAB Enhanced Stream Mode 
Figure 2: DAB IPDC Protocol Stack 

4.3 IPDC data packet transport over DAB 

In IPDC, the payload consists of IP packets, which are used to carry streaming data as well as file carousels. IP 
datagrams are encapsulated into MPE sections, which in turn are carried in MPEG-2 TS packets. A comprehensive 
overview of this structure is given in TS 102 470 [2],clause 4.3. 

MPEG-2 TS packets carrying MPE sections containing IP datagrams with multiple IP addresses may be carried in a 
single DVB service component, i.e. they may share a single PID. To improve the power efficiency of the DAB IPDC 
system, it is recommended to group only such IP streams into one PID which are required for consuming a single 
service. 

The data rate assigned for a single PID is not fixed within an MPEG-2 TS. This allows statistical multiplexing between 
services, provided that the overall data rate of the transport stream does not exceed a given limit determined by the 
DAB multiplex. 

Figure 3 depicts the mapping from AV sources to a single MPEG-2 TS. A number of AV sources is encoded using a 
common statistical multiplexing control, which assigns the data rates to the encoders of the sources. The output of the 
encoders is a set of IP streams with varying bandwidth demands. However the sum bandwidth requirement remains 
constant. 

The result of the subsequent IP encapsulation (MPE) is an MPEG-2 TS with a series of TS packets. 

NOTE: For DAB IPDC services the MPE-FEC option of MPE is not active (code rate R=l) as an equivalent 
forward error protection is provided by the DAB Enhanced Stream Mode ( see figure 5). 
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Figure 3: Mapping of IPDC Services into MPEG-2 Transport stream 

4.4 DAB IPDC data transport mechanism 

The DAB IPDC data transport mechanism enables DAB power saving modes at the presence of variable bit rate (VBR) 
services. The general idea is to split the incoming MPEG-2 transport stream over multiple sub-channels which allows 
selective decoding of only the required sub-channels for the currently active application in the receiver. The granularity 
of the power saving is defined by the number of sub-channels used by the DAB IPDC Service. 
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Figure 4: DAB IPDC transport mechanism for MPEG-2 transport streams 
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The DAB IPDC data transport mechanism defines the transport of media content encapsulated in an MPEG-2 TS over 
the DAB system as illustrated in Figure 4. 

Incoming MPEG-2 TS packets (188 bytes per packet) are passed to the TS-splitter. 

The TS-splitter distributes packets to DAB sub-channels according to their PIDs and generates the 
Sub-channel Assignment Table (SAT). The mapping of PIDs to sub-channels may be changed dynamically. 

TS-packets with different PIDs may be transmitted over the same DAB sub-channel. 

The DAB IPDC transport mechanism requires sub-channels of equal size to ensure correct packet order at the 
receiver. 

Each sub-channel is protected according to TS 102 427 [8]. 

The SAT is transmitted in MPEG-2 TS packets over the primary sub-channel of the DAB IPDC Service. It 
contains all information to identify the sub-channels which must be decoded in order to receive all packets of a 
certain PID. 

If the SAT is corrupted or missing, the receiver may decode all sub -channels of the DAB IPDC Service 
including the packets with PIDs that are not required. 

All packets common to all applications in the MPEG-2 TS such as PSI/SI and SAT shall be transmitted in the 
primary sub-channel of the DAB IPDC Service. 

Other common data packets like EPG information should be transmitted in the primary sub-channel. The 
primary sub-channel may also be used to carry other application data of IPDC Services. 

The location of the primary sub-channel within the DAB multiplex is described in clause 6. 

The non-primary sub-channels should be decoded only upon request if they contain packets of a required PID 
for a consumed IPDC Service. 

4.5 Power saving 

Power saving can be achieved by two means: 

• macro time slicing 

• micro time slicing 

For macro time slicing as shown in Figure 5 (left), AA^ programmes are transmitted in time multiplex using all 
sub-channels during the active time. During the period, where no packets of the currently consumed AA^ programme 
are transmitted, the demodulator and channel decoder can be switched off. 

For micro time slicing see Figure 5 (right) all AA^ programmes are transmitted in parallel, and every programme 
occupies only a subset of the available sub-channels. Those sub-channels, which are not used by the currently consumed 
programme can be switched off. 
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Figure 5: Macro time slicing (left) and micro time slicing (right) 



4.6 DAB IPDC service profiles 



The DAB IPDC Service allows profiles for enabling applications with different requirements in terms of data rates and 
complexity of implementation: 

Profile 1: One sub-channel per DAB IPDC service. Maximum data rate 768 kbit/s. No SAT. 

Profile 2: One to 11 sub-channels per DAB IPDC service. SAT transmitted for power saving using micro time slicing. 
Maximum data rate per IPDC service 768 kbit/s. 

Profile 3: Includes Profile 2, no restrictions on the maximum data rate. 

Profile 4: Includes Profile 2 and adds macro time slicing capabilities. 



5 Data transport in DAB IPDC systems 

5.1 Usage of IPDC architecture 

The defined IPDC architecture from the DVB-CBMS working group is used by DAB IPDC systems and it includes the 
specification of: 

• TS 102 470 [2] covers the usage of PSI/SI, the signalization of the IP Platform and the encapsulation of IP in 
MPEG-2 TS over DVB-H Systems. Differences in relation to DAB IPDC are covered by the present document 
in clause 5.3. 

• A number of elementary use cases are provided in TR 102 473 [i.l] accomplished by requirements and data 
flows. 

• A reference architecture for IPDC service delivery over DVB-H is defined in TR 102 469 [i.2]. 

• The information of available services is provided by an Electronic Service Guide (ESG). The datamodel, the 
representation format, the encapsulation and the transport of the ESG over DVB-H are defined in 

TS 102 471 [3]. 
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The set of specification documents applicable to Service Purchase and Protection for IPDC Services over 
DVB-H are defined in TS 102 474 [4]. 

The Content Delivery Protocols for streaming and file delivery services in IPDC over DVB-H are defined in 
TS 102 472 [5]. 



5.2 IP Transport 



The IP Packets are transported over Multi Protocol Encapsulation (MPE) in MPEG-2 sections. For locating the 
MPEG-2 sections the PSI/SI table INT contains the mapping of the IP address to the corresponding DAB IPDC Service. 
Transporting IP over MPEG is described in the DVB specification for data broadcasting [17] and the usage of MPEG 
PSI/SI tables is described in ISO/IEC 13818-1 [11] and TR 101 211 [i.3]. 

5.3 Transport stream PSI/SI specification 

The following rules are applied at the transmitter side: 

PSI/SI sections shall be located in the primary sub-channel of the DAB IPDC service. 

A Program Association Table (PAT) shall describe only one program, and its transmission period shall be no 
greater than 500 ms. 

A single Program Map Table (PMT) shall describe the whole IP Platform with its transported MPEG Services. 

A special method for efficient transmission of PMT sections can be used which is specified in clause 5.3.1. 

The transmission period of the PMT section, including PMT sections using the efficient transmission method 
specified in clause 5.3.1, shall be no greater than 500 ms, see Figure 7. 

The transmission period of original PMT packets with the PMT_PID given in the PAT shall be no greater than 
17 times the PAT transmission period, see Figure 7. 

5.3.1 Efficient transmission of PSI/SI and SAT sections 

This method can be used for transmitting a PSI/SI/S AT section if either: 

a) PAT packets (i.e. TS packets with PID 0) contain an adaptation field which does not contain private data bytes 
and the total number of padding bytes contained in that adaptation field and following the PAT section is 
greater than the length of that PSI/SI/S AT section; or 

b) PAT packets do not contain an adaptation field and the number of padding bytes following the PAT section is 
greater than the length of that PSI/SI/S AT section plus 3. 

For case A, the existing adaptation field shall be extended; for case B, an adaptation field shall be inserted. 

For all cases the adaptation field shall be dimensioned such that the PAT section is moved to the end of the TS packet. 
Any existing padding bytes shall be removed and a block of private data bytes shall be inserted, setting both the 
transport_private_data_flag and the transport_private_data_length fields accordingly. 

The PSI/SI/S AT section, starting from the table_id and including the CRC_32 field, shall be inserted into the block of 
private data bytes, starting at the byte that follows the transport_private_data_length field, see Table 1. 

If the first PSI/SI/S AT section (e.g. the PMT section) does not extend to the last byte of the block of private data bytes, 
any sequence of DVB SI sections which comply to the section syntax specified in [11] (clause 2.4.4.11) can be 
transmitted if its size is less or equal the number of remaining private data bytes. 
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Table 1 : Syntax of sections inserted into the block of private data bytes 
in the transport stream adaptation field (see Table 2-6 of [11]) 



Syntax 


No. of bits 


Mnemonic 


if ( transport private data flag = = '1') { 






transport_private_data_length 


8 


uimsbf 


remaining_bytes = transport_private_data_length; 






while ( next byte != OxFF ) { 






table_id 


8 


uimsbf 


section_syntax_indicator 


1 


bslbf 


private indicator 


1 


bslbf 


reserved 


2 


bslbf 


section_length 


12 


uimsbf 


for (i = 0; i < section_length; i++) { 






section payload byte 

} 

remaining bytes = remaining bytes - (section length + 3) 

} 

for ( i = 0; i < remaining bytes; i++ ) { 


8 


bslbf 










padding byte 

} 
} 


8 


bslbf 



transport_private_data_flag - A 1-bit flag set to a value of 1' indicating that the adaptation field contains one or more 
private_data bytes as specified in [11] (Table 2-6). 

transport_private_data_length - The transport_private_data_length is an 8 -bit field specifying the number of 
private_data bytes immediately following the transport private_data_length field as specified in [11] (Table 2-6). It shall 
be set to the maximum number of bytes available by discarding all padding bytes. 

tablejd - This 8-bit field shall be copied from the inserted section. It identifies the table type the section belongs to. 
The semantics is specified in MPEG-2 Systems [11] (Table 2-6) and DVB Service Information EN 300 468 [9] Table 2, 
respectively. 

section_syntax_indicator - This is a 1-bit indicator which shall be copied from the inserted section. 

privatejndicator - This is a 1-bit field which shall be copied from the inserted section. The semantic of this field 
depends on the table_id. It is defined by the appropriate table specification. 

sectionjength - A 12-bit field. It specifies the number of remaining bytes in the private section immediately following 
the sectionjength field up to the end of the section. The value of this field shall be copied from the inserted section. 

section_payload_byte - This byte is copied sequentially from the section to be transmitted using the method described 
here, starting from the byte after the sectionjength field and including the CRC_32 field of the section. 

padding_byte - This byte shall be set to OxFF and disregarded by the decoder. 
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Figure 6: Transport of PMT section in private data block of adaptation field in PAT packet 

If this transmission method is used for PMT sections, the first TS packet which contains a PMT section (referred to as 
"PMT packet" below) shall be transmitted unchanged as shown in Figure 7. Any following PMT packet shall be 
compared to the last transmitted PMT packet, disregarding the continuity counter field of the TS packet header. If the 
information changed, the new TS packet shall be transmitted. 

If the information did not change, the PMT packet is dropped, unless the transmission interval of original PMT packets 
exceeds the maximum value specified in clause 5.3. In the latter case, the original PMT packet is transmitted, adjusting 
the continuity counter field so that it increases by one with each remaining PMT packet. 
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Figure 7: Transmission period of PS! packets in original TS and using efficient 
PMT transmission as specified in clause 5.3.1 

If this transmission method is used for other PSI/SI/S AT sections, the present document does neither specify if nor at 
which maximum transmission period original packets shall be kept in the TS. 
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5.4 IPDC data transport service 
5.4.1 Sub-channel organization 

The DAB IPDC data transport system provides means to carry MPEG2 transport stream packets over a group of DAB 
sub-channels. This group consists of a fixed number of DAB sub-channels with equal size and a single DAB service is 
used to signal this group and each sub-channel in the group is a service component of that service. The number of 
sub-channels may be any number between 1 and 1 1 inclusive. The upper limit is caused by the limitation of the number 
of sub-channels in a DAB service, as explained in EN 300 401 [7], clause 6.3.1. 
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Figure 8: DAB IPDC service structure 

Other sub-channels might exist in parallel and may carry other services, which are fully independent of the DAB IPDC 
service. Also multiple DAB IPDC services may be carried in parallel within the same DAB multiplex. 

NOTE: It is recommended that all sub-channels of a group occupy neighbouring segments of the CU space, as 
this improves the power saving capabilities of receivers. 

The sub-channels in a DAB IPDC sub-channel group are implicitly ordered by the sequence that they occur in as 
service components in the DAB signalling. It is recommended that this order also reflects the position of the 
sub-channels within a logical frame. 

On the transmitter side, TS packets are distributed amongst the group's sub-channels. The assignment of TS packets to 
the sub-channels is done based on their PID value: A subset of the sub-channel group is assigned to each PID in the 
transport stream and TS packets with a distinct PID value are distributed only over the sub-channels in that subset. The 
defined subsets may overlap, i.e. each PID value may be mapped to a subset consisting of an arbitrary choice of 
sub-channels in the group. 

The signalling specified in clause 5.4.4 provides a way to communicate the mapping between PID and sub-channel 
subset to the receiver. The receiver may then choose to receive only those sub-channels which contain TS packets with 
"interesting" PID values. 

Before transmission of TS packets over a stream mode sub-channel, additional error protection using a Reed-Solomon 
outer coder and an outer interleaver is applied as specified in TS 102 427 [8]. 
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Some restrictions apply for the primary sub-channel of the IDPC Transport Service: 

The SAT and all packets common to all apphcations in the MPEG-2 TS (PAT, PMT, CAT, TSDT) shall be 
transmitted in the primary sub -channel. 

Other common data packets hke EN 300 468 [9]. 

NIT, SDT, EIT and TDT packets as well as EPG information shall be transmitted in the primary sub-channel. 

The primary sub-channel may be also be used to carry other application data of the DAB IPDC service. 

Any table that fits can use the compact transmission mode specified in clause 5.3.1. 

5.4.2 Data transport over multiple sub-channels 

When TS packets of a single PID are transmitted over multiple sub-channels, provisions must be taken to maintain the 
sequence of the TS packets from the transmitter to the receiver side. This clause specifies the means which provide 
sequential delivery of TS packets over the DAB IPDC data transport system. The description in this clause is only a 
theoretical description of the algorithm. Practical implementations might differ, as long as they exhibit the same 
behaviour and lead to the same sequence of the TS packets in each sub-channel. 

For each sub-channel a buffer is provided, which is filled with complete TS packets and emptied with the data rate of 
the sub-channel. The capacity of each buffer should be at least as large as the amount of data which is transmitted on a 
single sub-channel in a single CIF plus some additional space to lever the statistical arrival of TS packets. Data is 
extracted from all buffers simultaneously and in parallel at the individual rates of the sub-channels and fed into the 
DAB stream mode data processing unit. If no data is available in one of the buffers, then a stuffing TS packet must be 
inserted in that buffer. 

The TS packets in the MPEG-2 TS are assigned to the sub-channel buffers based on the following rules as illustrated in 
Figure 9: 

• First determine the set of sub-channels which may be used to carry the next TS packet based on its PID. 

• Then check the fullness of all buffers associated with the sub-channels in that set. 

• Select the buffer which contains the least data. If two or more buffers contain the same amount of data, then 
select the sub-channel with the lowest order as defined by clause 5.4.1. 

• If none of the buffers provides sufficient free space to carry the TS packet, then this packet cannot be 
transported and must be discarded. 

NOTE: The algorithm for multiplexing multiple PIDs into several sub-channels is not in the scope of the present 
document. 
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pid :=PID of TS packet 

scSet := set of subchannels(pid) 

index := 

selected := none 

maxAvail := 



index := index + 1 




Determine available buffer space: 
avail := buffer[scSet[index]]. avail 




selected := scSet[index] 
maxAvail := avail 



drop TS packet 



move TS packet to 
selected buffer 



o 



Figure 9: Transmitter TS-packet sub-channel selection process 

On the receiver side, sub-channel buffers are provided from which TS packets are extracted. The receiver only needs to 
monitor those sub-channels which contain "interesting" data. For this purpose, the receiver may compute the union of 
all sub-channel subsets carrying interesting PID values. Alternatively, a receiver may ignore the PID-to-sub-channel 
mapping and decode all sub-channels of the DAB IPDC service. The receiver then reconstructs a transport stream 
according to the following rules as illustrated in the flow diagram Figure 10: 

• After reception and decoding of a complete logical frame, fill all buffers simultaneously with the data 
contained for the corresponding sub-channels in that logical frame. 

• Find the buffer which contains the most data. If multiple buffers contain the same amount of data, process 
them in ascending order of the start CU number of the sub-channels. Extract one TS packet from this (these) 
buffer(s). 

• Repeat the previous step until none of the buffers contains a whole TS packet. 
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scSet := set of monitored 
subchannels 



index := 
selected := none 
maxSize := 



index := index + 1 



take TS packet from /__ 
selected buffer / 




Determine data in buffer: 
size := buffer[scSet[index]].size 




selected := scSet[index] 
maxSize := size 



1 r 

o 



Figure 10: Receiver TS-packet extraction process 

These rules guarantee that the order of TS packets is maintained regardless how many sub-channels are used and which 
subset of sub-channels the receiver monitors. In order to receive all TS packets for a specific PID, the receiver has to 
monitor at least those sub-channels which belong to the set of sub-channels used by the consumed IPDC service. 

5.4.3 TS synchronization 

To facilitate the definition of the TS packet order over several sub-channels, all sub-channels in a DAB IPDC 
sub-channel group must be synchronized. This means that in all sub-channels in a single logical frame that the 
SYNC byte (0x47) of a TS packet shall be at the same relative position. It is also required that the outer interleavers for 
all sub-channels in a DAB sub-channel group are synchronized. 

Synchronized sub-channels also ease the synchronization on TS packet boundaries because data on any number of 
sub-channels may be used to achieve TS synchronization. Also, synchronization is maintained even if sub-channels are 
removed from, or added to, the set of currently decoded sub-channels. 
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5.4.4 Definition of Sub-channel Assignment Table 

The Sub-channel Assignment Table (SAT) defines the correspondence of DAB IPDC sub-channels with PIDs of the 
MPEG-2 Transport Stream. It facilitates power savings by avoiding decoding of unnecessary sub-channels in the 
receiver. 

Two table types allow different power savings: 

• The mandatory long-term (static) SAT defines the maximum occupancy of sub-channels by a certain PID. 

The configuration shall be stable for at least 60 seconds. 

The repetition interval shall be smaller than or equal to 6 seconds. 

Changes in the configuration shall be signalled at least three times in a 6 seconds interval prior to the 
configuration change. 

• The optional short-term (dynamic) SAT defines the currently used sub-channels by a certain PID. 

The configuration shall be stable for at least 1 second. 

The repetition interval shall be smaller than or equal to 1 second. 

The next configuration shall be signalled once 0,5 to 1 seconds prior to the configuration change. 

• PIDs which are transported in the primary sub-channel of the DAB IPDC Service shall not be signalled in the 
SAT. 

• For the case of a single sub-channel DAB IPDC Service, the SAT can be omitted. 

The Sub-channel Assignment Table shall be transmitted either according to clause 5.3.1 or using MPEG-2 TS 
Null-Packets according to the specifications in Table 2 and Table 3. 

Table 2: SAT transport packet definition 



Syntax 


No. of bits 


Restrictions 


Transport packet ( ) { 








sync_byte 


8 


"0x47" 




transport_error_indicator 


1 






payload unit start indicator 


1 
1 






transport_priority 
PID 


"0" 




transport scrambling control 


13 


"0x1 FFF" 




adaptation field control 


2 


"00" 




continuity counter 


2 


"01" 




for (i=0; i < 184; i++) { 


4 






data byte 








} 
} 


8 







payload_unit_start_indicator - This 1-bit flag indicates that the TS packet carries the first byte of a SAT. The packet 
with section_number equal to zero shall have a payload_unit_start_indicator = T, all other packets shall have a '0' 
indicator. 
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Table 3: SAT section definition 



Syntax 


No. of bits 


Restrictions / Notes 


sub-channel_assignment_table ( ) { 






table_id 


8 




section syntax indicator 


1 
1 




private indicator 




reserved 




private_section_length 


2 




table_id_extension 


12 




reserved 


16 




version_number 


^ 




current next indicator 


5 




section_number 


1 
8 
8 




last section number 
if (section number == '0') { 
activation_time 




expiry time 

} 


16 




size_of_PID_list 


16 




for (i=0; i < size_of_PID_list; i++) { 






reserved 


8 




elementary PID 




size of sub-channel list 
for (j=0; j < size of sub- 


3 




channel_list ; j++) { 


13 




service component index 

} 

if ((size of sub-channel list mod 2) 


4 




4 




= = 0) { 






reserved 






} 
} 


4 




CRC 32 
} 


32 





table_id - Shall be set to 0x80 for static SAT and 0x81 for dynamic SAT (user defined). 

section_syntax_indicator - A 1-bit indicator, which is set to T indicating that this is a private section which follows 
the generic section syntax specified by [11] beyond the private_section_length field. 

private_indicator - 1-bit indicator, which is reserved for future use. 

private_section length - This is a 12-bit field, the first two bits of which shall be "00". It specifies the number of bytes 
of the section, starting immediately following the section_length field and including the CRC. The section_length shall 
not exceed 1 021 so that the entire section has a maximum length of 1 024 bytes. 

table_id_extension - Shall be set to OxEDAB. 

version_number - This 6 bit field is the version number of the SAT. The version number shall be incremented by 1 
modulo 64 whenever the definition of the SAT changes. When the current_next_indicator is set to T, then the 
version_number shall be that of the currently applicable SAT. When the current_next_indicator is set to '0', then the 
version_number shall be that of the next applicable SAT. Static and dynamic SAT have independent version numbers. 

current_next_indicator - A 1-bit indicator, which when set to T indicates that the SAT sent is currently applicable. 
When the bit is set to '0', it indicates that the table sent is not yet applicable and shall be the next table to become valid. 

section_number - This 4-bit field gives the number of this section. The section_number of the first section in the SAT 
shall be 0x00. It shall be incremented by 1 with each additional section in the SAT. 

last_section_number - This 4-bit field specifies the number of the last section (that is, the section with the highest 
section_number) of the complete SAT. 

activation_time - This 16-bit field specifies the number of packets, counted in the primary sub-channel, after which the 
table becomes valid. 

expiry_time - This 16-bit field specifies the number of packets, counted in the primary sub-channel, after which the 
table becomes invalid. 
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elementary_PID - A 13 -bit field specifying the PID of the Transport Stream packets to which the following 
sub-channel assignment refers. 

size_of_sub-channel_list - The number of sub-channels associated with the elementary_PID. 

service_component_index - The number of the associated sub-channel with the elementary_PID according to the 
definition in 6.4.1. The number range is 1 to 1 1, with the first sub-channel having the index 1. 

CRC_32 - CRC checksum according to MPEG-2 Systems [11]. 



User application signalling 



The transport of IPDC services within a DAB multiplex is signalled in the FIGO/13 (see EN 300 401 [7]) with a User 
Application type value according to TS 101 756 [1] with value corresponding to "IPDC service". The user application 
data field shall carry two one-byte fields: the first byte carries the DAB IPDC ApplicationTypeld, the second the 
DAB IPDC Profileld - indicating the profiles of the specific apphcation decoder that should be used to decode the 
streams of the IPDC services. Receivers shall ignore any user application data following the DAB IPDC-Profileld field: 

• these bytes might carry data for future amendments. 

The DAB IPDC application types defined are detailed in Table 4. 

Table 4: DAB IPDC application types 



DAB IPDC ApplicationTypeld 


DAB IPDC Application Type 


0x00 


general DAB IPDC transport service 


0x01 


audiovisual service 


0x02 to Oxff 


reserved 



General DAB IPDC transport service: The general DAB IPDC transport service enables the transport of one IPDC 
service or a set of several IPDC services. The identification of the IPDC services and the associated application 
decoders is indicated by the ESG carried within the primary service component, see Annex C. 

Audiovisual service: The DAB IPDC-transport service carries one or more audiovisual services. The audiovisual 
services shall follow the rules presented in TS 102 005 [6]. 

DAB IPDC Profileld: 

The second user application data field (1 Byte) shall carry the DAB IPDC Profileld which shall indicate the profiles of 
the specific DAB IPDC transport and applications decoder that should be used to decode the streams of the IPDC 
service The DAB IPDC Profileld is split into two parts; the first nibble indicates the DAB IPDC Profile Version as 
specified in clause 4.6, the second nibble indicates the DAB IPDC Profile Level. For a specific value of the 
DAB IPDC Profile Version the required decoder capabilities can be profiled in such a way that a decoder with a higher 
profile level can decode all applications signalled with a lower DAB IPDC Profile Version value. 
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Annex A (normative): 

DAB IPDC reference receiver 



The DAB IPDC receiver comprises a DAB processor for Enhanced Stream Mode decoding of multiple sub-channels, an 
DAB IPDC processor for recombining a data stream from multiple sub-channels and an MPEG-2 processor which 
decodes the media content. 
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Figure A.1: DAB IPDC reference receiver model 

The Sub-channel Assignment Table is generated from the SAT packets and contains the PIDs to sub-channels 
mapping. Up to four tables are continuously updated: 

• the current static SAT; 

• the next static SAT; 

• the current dynamic SAT; 

• the next dynamic SAT. 

If available, the optional dynamic SAT overrides the static SAT. 

A sub-channel is active, if the current SAT indicates that it contains packets with required PIDs. 

The MPEG-2 TS processor must signal all PIDs required for the current IPDC Service to the DAB IPDC processor. 
The DAB IPDC processor keeps the PID table of required PIDs in memory. 

The Sub-channel Selector activates sub-channels according the PID table and the information of the SAT. 
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The Sub-channel Combiner reads packets from the ESM sub-channels and reconstructs the correct order of packets. 

• Packets are read from the ESM decoders in a cychc manner and ascending order. 

• In each cycle, one packet is read from each active sub-channel and output to the MPEG-2 TS processor. 

• Packets of inactive sub-channels are discarded. 

• The Sub-channel Combiner must ensure that only valid packets form the ESM sub-channels are passed to the 
MPEG-2 TS processor. Invalid packets which contain corrupted data generated during the outer decoder run-in 
and run-out phase must be discarded. 

• The output of the Sub-channel Combiner may also contain packets that are not needed. 

• The primary sub-channel is always active. 
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Annex B (normative): 

DAB IPDC receiver procedures 

The DAB IPDC receiver must implement the following procedures: 

• If a new PID is requested by the MPEG-2 TS processor: 

the DAB IPDC processor reads the Sub-channel Assignment Table to find the required sub-channels for 
the requested PID. 

If a new sub-channel is required: 

■ the DAB IPDC receiver initializes the outer decoder instance for this sub-channel and waits for the 
completion of the outer deinterleaver run-in; 

■ the Sub-channel Combiner is reconfigured for the new sub-channel mapping. 

• If a PID is disabled by the MPEG-2 TS processor: 

the DAB IPDC receiver reads the Sub-channel Assignment Table to find the required sub-channels for 
the PID. 

If a sub-channel is not needed any more: 

■ the Sub-channel Combiner is reconfigured for the new sub-channel mapping; 

■ the DAB IPDC processor stops the outer decoder instance for this sub-channel. 

• If a new SAT is transmitted, the DAB IPDC receiver shall: 

store the new Sub-channel Assignment Table, and select the required sub-channels for the currently 
active PIDs; 

initiate the baseband decoding of the new sub-channels and start the outer decoder run-in; 

wait for the new SAT to become valid; 

reconfigure the Sub-channel Combiner for the new sub-channel mapping; 

stop the baseband processing and outer decoder of unneeded sub-channels. 

Upon start of decoding an IPDC service, the following procedure shall be used: 

Only the primary sub-channel of the DAB IPDC service is selected. 

The DAB IPDC receiver decodes SAT packets and stores the PID to Sub-channel Assignment Table(s). 

The MPEG-2 TS processor requests the PAT from the DAB IPDC receiver. 

The PAT is processed by the MPEG-2 TS processor and required PIDs are signalled to the DAB IPDC 
receiver. 

The MPEG-2 TS processor can request more PIDs or disable PIDs at any time. 
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Annex C (informative): 

Discovery of IPDC Services over DAB 

For the discovery of an IPDC Service over DAB several steps are necessary. These steps are detailed in Figure C.l 




Figure C.1 : Discovery of an Video Service on DAB IPDC Systems 

Step 0. Bootstrapping of DAB IPDC Systems - The Bootstrap process is the entry point for setting up terminals to 
receive the Electronic Service Guide (ESG). This is done by a Bootstrap ESG which is also an IPDC Service at a fixed 
location. Bootstrapping of IPDC Devices is described in clause 9 of the ESG Specification for IPDC over DVB-H [3]. 

The steps for reception of ESGs are from the network layer the same which are necessary for reception of video 
services. These steps are described in detail below. The ESG and other content is transported over the IP based protocol 
FLUTE (File Delivery over Unidirectional Transport, RFC 3926 [16]). How FLUTE has to be used in IPDC Systems is 
described in the Content Delivery Protocols (CDP) Specification for IPDC over DVB-H [5]. 

The representation of the ESG is done in XML and the data model is described in the ESG Specification for IPDC over 
DVB-H [3]. Additional to the ESG files the content delivery session can contain ESG Auxiliary Data. This is data 
which is referenced from an instance of the XML based Data Model e.g. an SDP file, an HTML page or a PNG file. 

Step 1. Discovery of the Video Services - For discovering of video services the ESG has to be available on the 
Terminal. The ESG is interpreted and presented by an ESG Application and lists all available services. The Selection of 
a service triggers the reception of necessary data for the service. 

Step 2. Mapping of the Video Services to an IP Address - For the description of each video services the ESG 
contains a session description with the SDP (Session Description Protocol) Syntax. This covers the details for the 
terminal to receive and interpret the service. The SDP contains the parameters of audio and video codec for decoding 
and the IP Address and Ports for locating the service. 

Step 3. Mapping of the IP Address to an MPEG Service - The mapping of the IP Address to the corresponding 
MPEG-2 Service is done by the MPEG-2 TS Processor. Therefore the PSI/SI Decoder has to parse the tables, the 
parsing steps are listed below. 
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The IP Packets are transported over Multi Protocol Encapsulation in MPEG-2 sections. For locating the MPEG-2 
sections the INT has to be parsed which contains an mapping of the IP address to the corresponding DAB IPDC 
Service. Transporting IP over MPEG is described in the DVB specification for data broadcasting (EN 301 192 [17]). 
When the DAB IPDC Service is located, the PID is announced to the PID Filter and the PID Filter delivers the filtered 
MPEG-2 sections to the MPE IP-Decoder / Media Decoder for further processing. The usage of MPEG PSI/SI tables is 
described in ISO/IEC 13818-1 [11] andTR 101 211 [i.3]. 

PSI/SI parsing steps for receiving the PID of a corresponding IP Address, an example for these steps is illustrated in 
Figure 3 of EN 301 192 [17]: 

parse the PAT to receive the PIDs of all available PMTs; 

parse private data within adaptation fields of PAT packets for PMT sections as well as for other sections 
(DVB SI) transmitted according to clause 5.3.1; 

parse PMTs to receive the PID of the INT; 

alternatively parse the NIT to receive the PID of the INT, but the above described method is the preferred one 
due to the low transmission rate of the NIT; 

parse INT for mapping the IP addresses to PIDs. 

Step 4. Mapping of the PID to a DAB Sub-channel - The Sub-channel Selector receives from the PSI/SI Decoder the 
PID which contains the selected IPDC Service. The mapping from the PID to the corresponding sub-channel is done by 
means of the Sub-channel Assignment Table as described in clause 5.4.4 and annex A. 
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Annex D (informative): 
Variable Bit-rate Services 



The bit rate needed to transmit an individual video sequence with good subjective quahty depends on the image content 
and varies over time. For instance a sports programme with strong motion needs a higher bit rate than a static scene 
containing a news anchorman when coded at the same visual quality. The maximum bit rate of a transmission channel is 
fixed and therefore restricts the number of simultaneously broadcasted programmes. 

In conventional systems usually each encoder runs at a fixed data rate for each single programme, which means that 
large image quality variations can occur due to scene changes. In order to always ensure a minimum video quality, the 
bit rate assigned to each programme should be sufficient even for scenes which are difficult to encode. Hence, the 
system is designed for the worst-case scenario, i.e. for the most difficult-to-code programme. Coding all scenes at the 
same bit rate results in wasting resources, because many scenes could be encoded at a lower bit rate with similar 
subjective quality) (see Figure D.l) 
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Figure D.1 : Rate distortion curves for different programmes with worst case and 

mean data rate per programme 

In contrast to that a statistical multiplex system uses dynamic bit rate allocation for each programme in a transmission 
channel while keeping the overall bit rate constant. This allows saving bit rate in low motion video which can be used to 
improve the quality of programmes that are harder to encode. A requirement for successfully exploiting these rate 
savings is that at least some of the programmes are easier to encode than the others. But the probability of similar 
content decreases with an increasing number of programmes in a typical broadcasting environment. 

Tests have shown that when encoding 4-6 programmes it is possible to save typically 25 % of the bit rate which was 
needed at fixed rate to guarantee the same minimum video quality. This means that 5 or 6 programmes (QVGA, Service 
Class B) can be transmitted in one DAB ensemble instead of 4 for fixed rate coding. 
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